home *** CD-ROM | disk | FTP | other *** search
/ United Public Domain Gold 4 / United Public Domain Gold 4.iso / tbag / tb056.dms / tb056.adf / Docs / Imploder.docs < prev    next >
Text File  |  1978-12-16  |  10KB  |  217 lines
  1.  
  2. ------------
  3. Introduction
  4. ------------
  5.  
  6. The Imploder allows you to reduce the size of executable files while letting
  7. them retain full functionality. There are other "crunchers" or "packers"
  8. available for the Amiga, but none are as mindful of the complexities of your
  9. Amiga system as the Imploder. In addition to this, its algorithms are more
  10. efficient, both in terms of speed, and size reduction. ¹
  11.  
  12. Basic operation is clicking and using pull-down menus. If you can't figure
  13. it out, you're not likely to be in need of using the Imploder anyway.
  14.  
  15. Though operating the Imploder isn't hard, the complexities of the Amiga
  16. give rise to the need for imploding different types of executable files in
  17. a number of different ways. This, and how to modify the various settings in
  18. order to effectuate proper behaviour is explained below.
  19.  
  20. Please note that not reading the manual won't inhibit you from using the
  21. Imploder; it automatically detects, and reacts to almost all exceptions,
  22. and for the vast majority files it suffices to just hit the "Proceed" gadget
  23. after loading has finished. However, if you want to make optimal use of the
  24. Imploder's capabilties, you should consult the section below. ²
  25. Also in this manual are datailed descriptions of the "explode.library".
  26.  
  27.  Enjoy.
  28.  
  29. ¹ IMHO
  30. ² preferably RTMF
  31.  
  32.  
  33. ------------
  34. The Imploder
  35. ------------
  36.  
  37. The implosion processing sequence consists of four steps;
  38. -Loading & Format Verification.
  39. -Hunk Merging & Reloc Table Cleanup.
  40. -Implosion.
  41. -Decrunch code installation, Overlay table adjustment and Saving.
  42.  
  43.  
  44. ** The Loader **
  45.  
  46. The Loader loads executable files you've specified into 1 big continuous
  47. buffer. I.a.w. in order to Implode a file, you'll need a continuous memory
  48. region as large as the file itself.
  49. During this loading process, the executable file is analyzed. Format defects
  50. cause the loader to either report an error, and abort processing, or to
  51. give a warning while ignoring or repairing the defect. The often reported
  52. warning "data hunk lengths don't match" is nothing to worry about, its given
  53. for programs that have a combined DATA & BSS hunk. This format is outside
  54. the executable file definition as given in the AmigaDOS manual, yet it is
  55. allowed by the DOS loader (which is much less critical about things).
  56.  
  57.  
  58. ** The Merger **
  59.  
  60. If selected, the merger will try to coalesce the hunks in a program. If used
  61. in a constrained manner, this will reduce the size of the program, and the
  62. chance of memory fragmentation. If you specify a large merge threshold, the
  63. resulting file will need large continuous regions of memory in order to
  64. load, thus reducing the chance of it being able to be loaded into a
  65. fragmented system.
  66. Note that the merger can be used independently of the implosion routine.
  67.  
  68. Merging an executable file might break it. This is because certain programs
  69. make assumptions about the format of their segment list. The most notable
  70. members of this group are BCPL programs and a few libraries and devices.
  71. Hunk merging is therefore automatically disallowed for these. Still, some
  72. other programs, especially selfdetaching programs might dislike being merged.
  73.  
  74. Regardless of whether a program has been merged or not, a reloc table
  75. cleanup routine is executed upon the file. This deletes empty reloc tables,
  76. coalesces matching reloc tables, and finally sorts the relocation offsets.
  77.  
  78. I've chosen for the imploder to process executables within a single
  79. buffer, without the need for additional backup buffers. Thus removing
  80. redundant information, and copying hunk data during the merging and
  81. reloc cleanup process involves moving or mirroring large parts of the
  82. buffer. This process might therefore take a while if the executable is
  83. large.
  84.  
  85.  
  86. ** The Crunch Routine **
  87.  
  88. The crunch algorithm can operate in turbo mode or in normal mode. The normal
  89. mode requires no additional memory, whereas the turbo mode needs some 300K of
  90. additional hashing buffers of which 256K must be continuous. The turbo mode
  91. kicks-in automatically whenever the required amount of additional memory can
  92. be allocated. It is about ten times faster than the normal implosion  mode.
  93. Note that the parameter window will report whether or not the current memory
  94. configuration allows the turbo to be enabled or not. You might try and free
  95. a few resources in order to make the target. Whenever you select a crunch
  96. mode (gadgets 0-8), your turbo capability will be reevaluated.
  97.  
  98. The crunch routine is responsible for the compression. The modes vary from
  99. 0 (Max. dist. = 128 bytes) to 8 (Max. dist. = 18K). The maximum distance
  100. related to each crunchmode specifies the maximum distance used when searching
  101. for redundant data. The larger crunchmodes therefore have a better chance of
  102. compressing data. As a rule of thumb, it can be said that the best results
  103. are obtained by selecting an as large as possible crunchmode given that the
  104. related maximum distance should not exceed about half the program's size.
  105. The time required to crunch a program increases proportionally to the maximum
  106. distance in case of non-turbo operation. The processing speed during turbo
  107. operation however, is only slightly affected by varying the crunch modes.
  108.  
  109.  
  110. ** Decrunch Code Installation, Overlay Table Adjustment and Saving **
  111.  
  112. The Imploder is able to install 4 different decrunch algorithms into imploded
  113. executables;
  114. Normal, Pure, Library and Overlayed.
  115.  
  116. NORMAL IMPLODED files are the default. They are generated when;
  117. -The "Crunch" gadget is enabled.
  118. -The "Library" gadget is disabled.
  119. -The program being processed is neither overlayed nor pure.
  120.  
  121. The decrunchcode of a normal imploded file scatter decrunches and relocates
  122. the program data into a collection of empty hunks that exactly resembles the
  123. hunk configuration (Segment list) of the original program (Supposing you have
  124. not applied hunk merging). The decrunching is done from a hunk containing
  125. the crunched data. This hunk is appended to the end of the segment list,
  126. and is freed when the decrunch process has completed. Thus an imploded file
  127. requires additional memory during decrunch time, yet this memory is freed
  128. after decrunching without causing memory fragmentation.
  129. Furthermore, the normal distribution of program-data across hunks is
  130. retained, thus allowing for the loading of imploded files into fragmented
  131. memory, and the proper distribution of hunks across chip and fast memory.
  132.  
  133. PURE IMPLODED files are generated when;
  134. -The "Crunch" gadget is enabled.
  135. -The "Library" gadget is disabled.
  136. -The program being processed is pure. (Has the pure bit set)
  137.  
  138. Pure imploded files are equivalent to normal imploded files, apart from the
  139. fact that the decrunch algorithm operates between a forbid and permit pair,
  140. thus preventing other processes to use the same code image before decrunching
  141. has completed.
  142.  
  143. LIBRARY IMPLODED files are generated when;
  144. -The "Crunch" gadget is enabled.
  145. -The "Library" gadget is enabled.
  146. -The processed executable isn't overlayed.
  147.  
  148. Library imploded files decrunch like normal or pure imploded files. Yet they
  149. have no decrunch code, but instead open a disk based library, and use that
  150. instead. The whole subject of the library and how it operates is rather
  151. complex. It will be described below.
  152.  
  153. OVERLAYED IMPLODED files are generated when;
  154. -The "Crunch" gadget is enabled.
  155. -the processed executable is overlayed.
  156.  
  157. Overlayed files are normal program files with additional appended hunks that
  158. are loaded during runtime. The mechanism for doing this is left upto the
  159. programmer, though a standard technique is specified in the AmigaDOS manual.
  160. The program therefore has to know at what offset in its executable the
  161. overlayed hunks start. This is communicated by means of an overlay table.
  162.  
  163. The imploder crunches the program part of overlayed files, and copies the
  164. overlay data at the end. It will try to adjust the offsets in the overlay-
  165. table accordingly. Note that because neither the format of the overlayed
  166. data nor the format of the overlay table are rigidly defined, this process
  167. might fail. If the imploder suspects that the overlay table wasn't adjusted
  168. properly it will give a warning.
  169. There is therefore no guarantee that imploding overlayed files will result
  170. in operative programs. Thus you should implode overlayed file only when you
  171. know what you are doing, and are willing to verify the results.
  172.  
  173.  
  174. -------------------------
  175. Using the explode.library
  176. -------------------------
  177.  
  178. Library imploding files is preferable, not only because the result is
  179. smaller, but also because the library is faster, and because it patches
  180. the AmigaDOS executable file loader, thus decrunching ANY executable file
  181. as soon as it is loaded into memory.
  182. Note that the Loadseg vector is patched in an "intelligent" manner; it
  183. will work for pre 1.4 kickstarts as well as BCPL free systems (1.4?)
  184.  
  185. There are a few problems though.
  186.  
  187. If library imploded files do not find the explode.library they will keep
  188. on trying to open it until they succeed. These programs will therefore
  189. hang until the LIBS: directory contains the library. A full piece of
  190. conditional startup and exit code would have nullified the advantage in
  191. using the library decruncher, which is its small size.
  192.  
  193. When a library imploded file is run from the WorkBench, and the
  194. explode.library isn't resident yet, exec will try to load the library
  195. from disk. The process's message port however is in use by the workbench
  196. reply message, and until it has been replied, it cannot be used by the
  197. DOS in order to send packets. Thus the DOS gurus.
  198.  
  199. Also, BCPL programs don't use the library jumptable. They therefore bypass
  200. the LoadSeg function patch. The result is that executables loaded from BCPL
  201. code are not automatically exploded.
  202.  
  203. Thus you should make sure the explode.library is always present in your
  204. LIBS: directory, and an early library imploded program is run in your
  205. startup-sequence in order to make sure the library makes itself resident
  206. before the WorkBench is active, or any non-program library-imploded
  207. executables are required.
  208. Also you should never crunch handlers if you don't have kick 1.4 or
  209. higher because handlers are still being loaded from BCPL code.
  210. Do not library-implode the explode.library! :-)
  211.  
  212. If you obey these restrictions, you may merrily go around your system
  213. and library-implode libraries, devices, fonts and even keymaps.
  214.  
  215.  
  216. #AJ
  217.